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DECLARATION OF MARTIN NATHANSON 
UNDER 37 CFR §1.131 

I, Martin Nathanson, having a post office address at 
29 Southvale Drive, Toronto, Ontario, Canada, M4G IGl, do 
hereby declare and say as follows: 

1. I am the original and only inventor of the 
subject matter disclosed and claimed in the above-identified 
U.S. patent application. I have reviewed the subject 
application, the February 2, 2005 Official Action, and the 
Amendment being submitted concurrently herewith, in preparing 
this Declaration. 

2. I conceived the subject matter of at least the 
inventions recited in independent Clainis 1, 19 and 20 prior to 
the January 27, 1999 filing date of U.S. Provisional 
Application 60/117^487 identified on U.S, Patent No, 6,295,492 
to Lang. Furthermore, I acted to diligently reduce to 
practice the subject matter of at least the inventions recited 
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in independent Claims 1, 19 and 20 from tho conception thereof 
up to at least January 21, 1999. Moreover, from a date prior 
to January 27, 1999, I diligently continued to work to reduce 
to practice the subject matter of at least the inventions 
recited in independent Claims 1, 19 and 20, and I aver that a 
constructive reduction to practice of that subject matter 
occurred at least as of the filing date of the subject 
application on December 14^ 2001* 

3. Enclosed as Exhibit A are copies of disclosure 
materials describing the conceived inveratlpri;? recited in 
independent Claims 1, 19 and 20. These materials were created 
prior to January 27, 1999, and establish that the invention 
was conceived prior to Jsknuary 27, 1999, Thcso materials al^o 
provide evidence that the invention was being diligently 
reduced to practice from the conception thereof up to at least 
January 27, 1999 • 

4. Exhibit A describes A method of collecting 
vehicle operation data from a vehicle for later transmission 
to a remote monitoring recipient in a manner to minimize the 
bandwidth requirements for the later transmission, comprising 
the steps of: 

- providing a vehicle on~board computing device; 

- providing a number of data acquisition modules, each to 
measure one or more operating characteristics of the 
vehicle, the operating characteristics corresponding 
to current values of a set of managed objects; 

- interfacing the vehicle on-board computing device with 
each of the data acquisition modules; 

- configuring the vehicle on-board computing device to: 
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a) form a diagnostic information base tor receiving 
and storing values for each of the managed objects 
from each of the corresponding data acquisition 
module?; 

b) assemble an event report based on information 
contained in the diagnostic information base; and 

c) package the event report in a protocol data unit 
according to an SNMP--dcrived protocol. (See Claim 1.) 

5, Exhibit A also describes A method of conveying 
vehicle operation data from a vehicle to a remote monitoring 
recipient, comprising the steps of: 

- establishing a data link between the vehicle and the 
remote monitoring recipient; 

- collecting vehicle operation data from data sources in 
the vehicle; 

- packaging the vehicle operation data in a data packet 
using protocol derived from SNMP; and 

- conveying the data packet over the data link^ the 
protocol data unit bei/)g issued in response to a 
request by the remote monitoring recipient and 
containing both the request and requested values in the 
request and being encapsulated within a single message 
and in a single unfragmented network packet. (See 
Claim 19.) 

6. Exhibit A also describes A computer implemented 
system for conveying vehicle operation data from a vehicle to 
a remote monitoring recipient, comprising: 
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an vehicle on-board computing device in contmunication 
with a number of vehicle operation data sources in the 
vehicle; 

- a wireless coiomunications device for establishing a 
wireless data link with the vehicle on-board computing 
device and the remote monitoring recipient; 



the vehicle on-board computing device being enabled to package 
the vehicle operation data in a data packet using protocol 
derived from SNMP for transmission to the remote monitoring 
recipient over the wireless data link. (See Claim 20.) 

7- Therefore, it is evident that the present 
application claims inventions that were conceived of and being 
diligently reduced to practice prior to January 21, 1999. 

8. I hereby declare that all statements made 
herein of our own knowledge are true and that all statements 
made on information and belief are believed to be true; and 
further that these statements were made with the knowledge 
that wilful false statements and the like so made are 
punishable by fine or imprisonment, or bbth^ under Section 
1001 of Title 18 of the United States Code, and that such 
wilful false statements may jeopardize th^si validity o£ the 
application or any patent issued thereon. 




tin Nathanson Date 
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From: 

To: 

Date: 




Martin Nathanson <martinn@smtp.Generation.NET> 
TOR4,M CTET2(SHOWE) 
•■■Kl 2:22pm 



The only Inventor to be named in the application Is myself 

Martin Daniel Nathanson 
5301 Cumberland Ave. 
Montreal, Qc« Canada 
H4V2P1 

Canadian citizen. 

The patent is to be assigned to a company. If we need to identify the 
company immediately, then it will be Transcontedi Corporation, which is my 
consulting company (federally chartered). 

I noticed some typographic errors in the UOBD.DOC that t sent you so I am 
attaching a new version. 

Please confimi that you have received my check and brochures. 



Thanks. 




From: 
To: 
Date: 
Subject 



Stuart Howe 

SMTPCm artinn@smtp.Generation.NEr^ 
Patent Documentation -Reply 



Martin: 



We have conducted a brief review of the documents you sent and will get back to you when we have the other 
infomiation you indicated was being sent. In the meantime. I need some infomiation regarding full names, 
addresses and citizenships for all Inventors and an indication whether the rights are going to be owned personally or 
be assigned to a company/third party. Please provide this information asap. 

Have a great long-weekend. Regards. 




From: Martin Nathanson <martinn@smtp.Generation.NET> 

To: T0R4.MC TET2(SH0WE) 
Date: (■■iK:28pm 
Subject Patent 

Attached are three (3) background documents. They are in Micrososft Word 7 
forniat. In case you have difficulty with this. I have also Included ASCI) 
text versions. 

The first two refer to our Mobile Automotive Telemetry System (MATS), as 
developed for the heavy equipment market. By the way, In case you were not 
aware (as I was not) that when people in the industry use the term 
"automotive marker, they spedfically means passenger cars. This is what we 
are targeting for the patent 

(1) MATSDATA.DOC is bask:ally a data sheet describing the hardware and 
software components of the system. I am mailing you a glossy product sheet 
with the retainer check. 

(2) MATSDESC.DOC describes the essential characteristics of the system which 
shouki interest an OEM (truck manufacture^. 

The third document was written last night and this morning and constitutes a 
initial draft of a technology description for the patent application, that I 
hope will allow you to orient yourself. Please note that I have not had any 
chance at all to talk to my partner who handled all the hardware and 
operating system software Issues, so there is probably a lot more to follow 
on these subjects. He has extensive experience In studying patent documents 
and should be able to help me get very "focused". 



Martin 



Universal On-Board Diagnostic Server 

The universal on-board diagnostic (U-OBD) server is a vehicular computer which 
provides remote access to on-board diagnostic data through a variety of communications 
channels* The U-OBD server maintains a database of automotive functions objects which 
record performance data and respond to requests for information from authourized 
clients. 



Purpose 

To provide universal, real-time, flexible accessibility to automotive on-board diagnostic 
(OBD) data and to ensure fiill Internet connectivity to any part of the vehicle, including 
a portable computing device. 

Client/Server Architecture 

The embedded software in the ETC is structured according to an object-oriented 
client-server model which allows all monitored automotive functions to appear as through 
they are local to the remote client device. Remote clients interface to an API (Application 
Programming Interface) which provides a well-defined set of function calls for the 
foUowmg capabilities: 

* Configuration of the U-OBD server to establish acceptable threshold values for each 
automotive function. When these thresholds are exceeded, the server creates alarm 
objects which stream and transmit themselves to the client. 

* Retrieval of automotive function data. The server can be requested to create and 
transmit reports for specific functions at user-defined intervals and for user-defined 
durations. 

* Registration of client processes to be notified when alarms and reports are received 
from the U-OBD server. 



Process Architecture (This section is subject to modification) 

The process architecture defines the active objects (threads or polled functions) running 
within the firmware embedded in the U-OBD server. The threads related to 
conmiunications shall be detailed m a subsequent version of this document. The primary 
active object which is unique to the U-OBD server is the monitor object provides the 
interface to both the OBD-2 Diagnostic Protocol and the DSP module and assures a 
real-tune flow of diagnostic information from these interfaces to client objects which have 
expressed their interest in this information. 



Commimications Architecture 
Internet Telemetry 

In order to provide a universal communications channels from any client to any mobile 
U-OBD server, the technology uses the Internet paradigm coupled with sub-network 
drivers to interface to whichever packet-switched mobile data communications networks 
for which the U-OBD is equipped with hardware access devices. (See Sub-network 
Datalinks). 

The embedded communications software therefore incorporates an object-oriented 
implementation of the complete Internet protocol suite, including IP(version 4), TCP, 
UDP, IGMR ICMP, SNMP and PPR 

IP Defines the packet switching framework for datagrams (packets) over the 
Internet. IP determines whether a datagram should be forwarded (routed) from one 
computer to another, given the destination address encapsulated in the datagram, or has 
reached its fiinal destination. 

TCP Transport Control Protocol. Provides reliable data delivery between two end 
points (nodes in the Internet) 

UDP User Datagram Protocol. Defines framework for (unreliable)delivery of 
individual IP datagrams 



IGMP Internet Group Message Protocol. Defines abstract method for multicast or 
broadcast from a single origin to multiple destinations. Useful when the same message 
needs to be sent to an entire fleet. It is therefore desirable to avoid the cost of 
re-transmission of the same message to each and every mobile unit 

This works only in the case where the underlying network technology supports 
this and provides an advantageous rate structure for group messaging. For instance, this 
is the case with Ericsson Mobitex. 

ICMP Internet Control and Message Protocol. Defines a set of control and error 
messages. In particular, ICMP allows routers to report failures to reach destinations and 
indicate to the originator of the datagram, the reason for the failure. This is critical in 
networks with mobile nodes which frequently fell into and out of "reachability". 



SNMP Simple Network Management Protocol. In conventional TCP/IP networks or the 
Internet, th^ provides for network administrators to have remote access to traffic 
statistics in routers and to remotely update address tables in routers. Examples of 



applicability are where OE manufacturers or the management of a large end-user fleet 
want to add additional sites from which TCP connections, with (or SCADA services 
from) mobile units can be established. This means that the corporate computing network 
is expanding and the job of a network administrator is to ensure that the computers 
responsible for routing traffic are aware of the address of new sites in order to properly 
route new traffic destined for these site. SNMP is used to accomplish this. The on-board 
computer must therefore "speak" SNMP in order to be kept abreast of new entities in the 
corporate network with which it can conmmnicate. 

PPP Point-to-point protocol. Used for serial connections between permanent Internet 
nodes and temporary nodes which "live" on the Internet for the duration of the 
connection. T^ically applies to the protocol between a personal computer and an Internet 
service provider over a telephone liidc. MATS uses this for connection between lap-tops 
or hand-held computers and the Engine Telemetry Computer, where the latter is the 
permanent Internet node. 

Note that the IP implementation incorporates a Router object which, assisted by 
innovations introduced in the ICMP implementation, is capable of identifying the 
least-cost route to a specific mobile unit when that server interfaces to more than one 
mobile data network. Furthermore, the IP implementation is for version 4 whereas the 
Internet Engineering Tksk Force (IETF) has recently adopted a new version which 
provides more support for mobility and dynamic routing to mobile Internet nodes. 
Implementation of this new version shall be incorporated in a second generation of the 
U-OBD technology. 



Sub-network DataLinks 

The sub-network datalinks are the drivers for each specific packet-switched mobile data 
technology for which the U-OBD server has a network access device (radio modem). The 
datalinks currently supported are Mobitex (Ericsson) and ARDIS (Motorola). Support for 
the ORBCOMM system (low-earth orbit satellite, VHF, data-only) is pending. 



InfraRed 

The U-OBD server incorporates a fiill implementation of the IrDA (Infrared Data 
Association) specification. This is a complete protocol stack, including a datalink layer 
IrLAP (Link Access Protocol), a sub-network layer IrLMP (Link Multiplexing Protocol) 
and SNMP-like protocol called IAS (Information Access Service). Each of these has been 
implemented as an object -oriented class derived from a base class which is shared with 
some other entity withm the communication system. 

The use of the entire IrDA stack is the basis for enabling the wireless, universal 
connectivity in the garage as described in the following section. However, at the same 
time, the IrLAP implementation is also a means of provided a wireless datalink for a PPP 
connection between the U-OBD server and a IrDA-enabled hand-held or portable 



computing device with Internet software. In this wy the U-OBD server also acts as an 
mobile Internet router/service provider 



Data Acquisition Links 

OBD-2 Diagnostic Protocol (This section is subject to extensive modification) 

OBD-2 Diagnostic Protocol is an SAE (Society of Automotive Engineers) standard for 
data retrieval from vehicular electronic control modules (ECM's). In addition to 
providing access to performance data via remote telemetry, the U-OBD server also 
provides a wireless IR (InfraRed) solution to the problem of heterogeneous physical 
interfaces (connectors and electrical signals) between the ECM's and diagnostic tools of 
various manufacturers. By implementing the OBD-2 diagnostic protocol as a datalink 
between itself and the ECM, the U-OBD server can offer transparent services to the 
diagnostician (mechanic) using the mformation access service (IAS) protocol of the IrDA 
(Infrared Data Association) specification. This achieves the followmg: 

* elimmates the need for cabling connections with vehicular computers for uploading of 
information m the garage. 

* capitalizes on the expected widespread availability of new hand-held computmg devices 
based on Microsoft's Windows CE (Computer Electronics) operatmg system. CE is a 
version of Windows specifically designed for these devices. Both the CE software and the 
devices comply with flie IrDA specification for standardized datalinks between computers, 
laptops, handhelds, printers, modems and cellular phones via infrared serial ports 
integrated into the hardware. 

* by enabling vehicular computers to upload their accumulated diagnostic data to an 
IrDA-compliant PDA (personnel digital assistant), a wide variety of additional 
possibilities becomes apparent. Since the PDA's are so ubiquitous, many passei^er car 
owners will own, and frequently carry with them, such devices. Furthermore, it will 
become more and more common for these devices to have integrated cellular phone 
modems or (packet radio modems) and to see them being used in conjunction with 
cellular phones. Therefore diagnostic mformation can be acquired by the car owner 
through the IR port in the PDA and transferred via modem to the garage, if requhred. 



NMEA 

Nation Marine Electronic Association is a protocol standard for exchange with a external 
GPS receiver. The NMEA is embedded in the U-OBD server in order to enable location 
services for a client as well as to attached location stamps to data reports and alarms. 




Analog and Digital Signal Processing 

The U-OBD server can be configured with a bank of analog and digital signal inputs for 
sensors not connected to an ECM. A digital signal processing (DSP) software module 
handles these u^uts and relays them to the active monitor object. 



Hardware 

(See Product Description). After allocation of three(3) RS-232 ports to the GPS receiver, 
radio modem and a satellite transceiver or cellular modem, one port remains for user 
access through an infrared link. The ETC (Engine Telemetry Computer) therefore 
incorporates an IrDA-compliant IR adapter for the spare serial port. 
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MOBILE AUTOMOTIVE TELEMETRY SYSTEM 
Product Description 

The primary features of the AMT Mobile Automotive Telemetry System are: 

* an on-board vehicular device which supports automotive sensor input and GPS 

* communications which is independent of the underlying radio network 

* Windows NT Base Station. 



Hardware 

Engine Telemetry Computer (ETC) 

* CPU 

* 16 analog input 

* 16 digital inputs 

* 2 RS-232 ports 

These are for user applications such as dispatching messaging to terminals in the cab. The 
external device can communicate with the ETC using TCP/IP and PPP (pomt-to-point 
protocol) and can therefore be addressed in Internet fashion by the Base Station or any 
other device using the Base Station as an Internet Protocol router. 

* 2 RS-485 ports 

These are to support the SAE (Society of Automotive Engineers) J1708 standard for data 
acquisition and control on boani trucks and biises. 

* GPS receiver 

* Radio network access device 

The ETC is designed to meet the harsh environmental, mechanical and electrical 
requirements of an automotive application. 

* -30 (C/ +60 (C operating temperature 

* designed for compliance with SAE (Society of Automotive Engineers) J1211 
(recommended environmental practices for electronic equipment) 

* designed for compliance with SAE J1113 (conducted and radiated susceptibility) 

* 10.000 hrs MTBF 



Base Station 



* Windows NT Computer 



Software 

Engine Telemetry Computer 

The software in the ETC is an entirely object-oriented design and implemented in C+ + . 
It consists of: 

* Intelligent digital signal processing module 

* SCADA ( Supervisor Control and Data Acquisition ) Server 

* TCP/IP protocol stack for wireless communications 

* Data privacy: where required, optional communications encryption is available (subject 
to export regulations). 

Together, these software components allow for the following capabilities of the ETC: 

* can be remotely configured by the Base Station 

* can report automotive and operational events to the Base Station 

* can route wireless data traffic to and from other computing devices in the vehicle 



Base Station 

The Base Station software is an entirely object-oriented design and implemented ui 
C++. It consists of: 

* SCADA client 

* OODBS (object-oriented database system) 

* TCP/IP protocol stack for wireless and LAN communications 



These software components allow the Ba^ Station to act as a client with respect to the 
ETC's, The Base Station may : 

* remotely configure the ETC software 

* request and receive ETC reports m real-time 

* store ETC reports in the OODBS 

* display real-time graphic representation of automotive functions monitored by the ETC 

* alert third-party systems of ETC alarms xising RPC's or Sockets. 
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MOBILE AUTOMOTIVE 
TELEMETRY SYSTEM 
Product Description 



Mobile Automotive Telemetry System 
Executive Summary 

The Mobile Automotive Telemetry System (MATS) is technology which grew out of the 
developers' experience with the application of mobile data conmiunications to fleet 
operations. It was recognized that there is a need, common to all fleets, for real-time 
monitoring of all automotive functions which could enable preventive maintenance 
programs to be driven by alarm incidents from the field. Automotive telemetry, as it has 
been implemented, consists of an on-board vehicular computer which reports exception 
conditions to the maintenance garage and responds to any queries that a mechanic issues 
from a work station in the garage, even while the vehicle is on the road- 

To achieve the communications Imk, MATS uses whatever mobile data facilities are most 
appropriate for the fleet in question, including public RF packet networks such as 
Ericsson's Mobitex or satellite systems such as ORBCOMM. The communications 
software architecmre treats each of these as a physical "sub-network" according to the 
Internet model (The prototype version of the ETC currently incorporates an access 
device - radio modem - for the Ericsson network). However, it is not simply a matter of 
following this model. MATS also incorporates an implementation of the Internet 
standards so that the on-board computer becomes Internet-addressable. 

This means that packet-based Internet communications with the vehicle becomes possible 
for a wide variety of applications. In addition to the link between a fleet maintenance 
department and the vehicle, there is also the potential for the Original Equipment 
Manufacturer's product support staff to assist end-user customers witfi technical diagnoses 
or to validate dealer warranty claims through remote monitoring. Regulatory bodies 
responsible for commercial vehicle licensing and highway safety can carry out remote 
electronic inspections. 

Furthermore, since there are xmxsy applications for mobile data exchange with the driver 
(eg. E-MAIL, dispatch, database query), the Engine Telemetry Computer (ETC) supports 
a PPP (point-to-point protocol) connection for portable or hand-held computing devices in 
the cab. This provides a TCP/IP communications platform to anywhere in the Internet in 
exactly the same fashion as does an Internet Service Provider (with the exception that the 
PPP link operates over a direct connection between the in-cab computer and the ETC 
instead of over a telephone line between the subscriber and the Internet Service Provider). 

In order to provide for a comprehensive monitoring capability, the ETC has a bank of 16 
A/D channels for sensor inputs, 16 digital (pulse) channels for discrete inputs (eg. 
tachometer, gear position, intrusion alarms) and RS-485 ports for interface to the SAE 
J-1708 data bus, in addition to the signal processing and J-1708 protocol software 
required to acquire various types of data. This hardware configuration is expandable to 
support both more inputs as well as discrete outputs for security applications. 



From: Martin Nathanson <martjnn@smtp.Generation.NET> 

To: TOR^CTET2{SH0WE) 
Date: 0lf^1:Z9pm 
Subject: Patent Documentation 

I realize that the documentation I have sent to you is a littte deficient In 
the "diagram department". Don't worry. This will be corrected soon. 



Martin 
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